68 - Relative lock-time using consensus-enforced sequence numbers
BIP: 68 source Layer: Consensus (soft fork) Title: Relative lock-time using consensus-enforced sequence numbers Author: Mark Friedenbach BtcDrak Nicolas Dorier kinoshitajona Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0068 Status: Final Type: Standards Track Created: 2015-05-28 Table of ContentsAbstractMotivationSpecificationImplementationAcknowledgmentsDeploymentCompatibilityReferences Abstract This BIP introduces relative lock-time (RLT) consensus-enforced semantics of the sequence number field to enable a signed transaction input to remain invalid for a defined period of time after confirmation of its corresponding outpoint. Motivation Bitcoin transactions have a sequence number field for each input. The original idea appears to have been that a transaction in the mempool would be replaced by using the same input with a higher sequence value. Although this was not properly impl...
78 - A Simple Payjoin Proposal
BIP: 78 source Layer: Applications Title: A Simple Payjoin Proposal Author: Nicolas Dorier Replaces: 79 Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0078 Status: Draft Type: Standards Track Created: 2019-05-01 License: BSD-2-Clause Table of ContentsIntroductionAbstractCopyrightMotivationRelation to BIP79 (Bustapay)SpecificationProtocolBIP21 payjoin parametersOptional parametersReceiver's well known errorsFee outputReceiver's original PSBT checklistSender's payjoin proposal checklistRationaleRespecting the minimum relay fee policyDefeating heuristics based on the fee calculationReceiver does not need to be a full nodeSpare change donationPayment output substitutionUnsecured payjoin serverImpacted heuristicsAttack vectorsOn the receiver side: UTXO probing attackOn the sender side: Double payment risk for hardware walletsReference sender's implementationTest vectorsImplementationsBackward compatibilitySpecial thank...
90 - Buried Deployments
BIP: 90 source Title: Buried Deployments Author: Suhas Daftuar Comments-Summary: Mostly Recommended for implementation, with some Discouragement Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0090 Status: Final Type: Informational Created: 2016-11-08 License: PD Table of ContentsAbstractMotivationConsiderationsSpecificationImplementationReferencesAcknowledgementsCopyright Abstract Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner signaling in block version numbers. Now that the chain has long since passed the blocks at which those consensus rules have triggered, we can (as a simplification) replace the trigger mechanism by caching the block heights at which those consensus rules became enforced. Motivation BIPs 34, 65 and 66 were deployed on mainnet using miner signaling using block version numbers. In short, new consensus rules were proposed for use in blocks with a higher version number (N+1) than the prevailing block versio...
123 - BIP Classification
BIP: 123 source Title: BIP Classification Author: Eric Lombrozo Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0123 Status: Active Type: Process Created: 2015-08-26 License: CC0-1.0 GNU-All-Permissive Table of ContentsAbstractCopyrightMotivationSpecification1. Consensus LayerSoft ForksHard Forks2. Peer Services Layer3. API/RPC Layer4. Applications LayerClassification of existing BIPs Abstract This document describes a classification scheme for BIPs. BIPs are classified by system layers with lower numbered layers involving more intricate interoperability requirements. The specification defines the layers and sets forth specific criteria for deciding to which layer a particular standards BIP belongs. Copyright This BIP is dual-licensed under the Creative Commons CC0 1.0 Universal and GNU All-Permissive licenses. Motivation Bitcoin is a system involving a number of different standards. Some standards are abso...